Confidential compute s390 #2528
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
To run the integration test for the |
|
Tasks to be done
|
schaefi
force-pushed
the
confidental_compute_s390
branch
from
e645ced
to
3727f6c
Compare
schaefi
force-pushed
the
confidental_compute_s390
branch
2 times, most recently
from
64eb91d
to
ac37b20
Compare
schaefi
force-pushed
the
confidental_compute_s390
branch
3 times, most recently
from
eab79a7
to
189ab2d
Compare
schaefi
force-pushed
the
confidental_compute_s390
branch
2 times, most recently
from
edd31da
to
9e418e9
Compare
schaefi
force-pushed
the
confidental_compute_s390
branch
2 times, most recently
from
14696e0
to
084d20f
Compare
schaefi
force-pushed
the
confidental_compute_s390
branch
from
a3e9f14
to
f14901a
Compare
| <hkd_cert name="/var/lib/se-certs/HKD-8562-024B858.crt"/> | ||
| <hkd_cert name="/var/lib/se-certs/HKD-8562-024B868.crt"/> | ||
| <hkd_cert name="/var/lib/se-certs/HKD-8562-024B878.crt"/> |
There was a problem hiding this comment.
Do you think this should be made generic?
There was a problem hiding this comment.
Hmm, I can't follow you, generic ?
There was a problem hiding this comment.
For example
<hkd_cert name="/var/lib/se-certs/HKD-8562-024B878.crt"/>
8562 is the model number of the IBM Z or LinuxONE server.
024B878 is the serial number of the server.
I think keeping the model number is OK but am asking if the serial number should be XXXXXXX, <serial number> or something else.
There was a problem hiding this comment.
Well the files as you see them here comes from packages. I created that packages with the files as I got them from IBM. I think we should not change the filenames in any way, the same applies to the filename of the CA or the revocation lists. The naming from its origin location should just not be touched. I also believe it's not a good idea to interpret the names in any way. We have zero influence here. That '024B878' is a serial number is nice but immaterial :) kiwi doesn't have to work with the certificate names and I don't see where it ever would have the need to do so. Therefore let's focus on the kis principle ... keep it simple, there are certificate files and the only thing we need to know is their location on the build system.
Or am I mistaken ?
schaefi
force-pushed
the
confidental_compute_s390
branch
5 times, most recently
from
becce41
to
22f1cb4
Compare
IBM SEL(Secure Execution for Linux) is supported for s390 KVM guests. SEL images used to start a confidential computing protected guest contain an encrypted boot image which encapsulates the kernel the initrd and the bootparams. The encrypted Image is provided by the KVM/hypervisor to the Embedded zFirmware of the system (the ultravisor device). The decryption keys are hardware based and each system has an individual keypool unique to that system. The root filesystem is LUKS encrypted with a random key produced by kiwi at build time and kept inside of the initrd which exists only inside of the encrypted boot image and the encrypted rootfs to allow kernel updates. The commit to support secure execution also comes with an integration test that provides profiled image builds to target SUSE's LinuxONE as well as IBM Cloud systems.
generateDS and other tools are needed and were forgotten to be added when we deleted the tox dependency
Allow to pass luks="random". In random mode use the generated keyfile as the only key to decrypt. This is only secure if the generated initrd also gets protected e.g. through encryption like it is done with the secure linux execution on zSystems
schaefi
force-pushed
the
confidental_compute_s390
branch
from
22f1cb4
to
43cd86d
Compare
Added IBM Secure Execution support on s390
IBM SEL(Secure Execution for Linux) is supported for s390 KVM guests. SEL images used to start a confidential computing protected guest contain an encrypted boot image which encapsulates the kernel the initrd and the bootparams. The encrypted Image is provided by the KVM/hypervisor to the Embedded zFirmware of the system (the ultravisor device). The decryption keys are hardware based and each system has an individual keypool unique to that system. The root filesystem is LUKS encrypted with a random key produced by kiwi at build time and kept inside of the initrd which exists only inside of the encrypted boot image and the encrypted rootfs to allow kernel updates. The commit to support secure execution also comes with an integration test that provides profiled image builds to target SUSE's LinuxONE as well as IBM Cloud systems.